UsageNotes: Excluded from schemas

UsageNotes: Excluded from schemas

UsageNotes: Excluded from schemas

Design Comments: A coded value that further classifies provider person role.

Valid provider role class type codes include:

'RH" - Regulated Health professional

'SS' - Sub-specialty .

Rationale: Allows for higher category specification of provider role access/permissions to clinical information.

UsageNotes: Excluded from schemas

Design Comments: Unique identifier for the Expertise.

Rationale: Required attribute supports the identification of the healthcare provider expertise.

Design Comments: A code for the expertise.

Includes 'Specialties', Sub-Specialties', etc.

Rationale: Populated attribute supports the identification of the healthcare provider expertise.

Design Comments: The effective date of the provider expertise in the healthcare provider role.

Rationale: Populated attribute supports the identification of the healthcare provider expertise.

UsageNotes: Excluded from schemas

UsageNotes: Excluded from schemas

Design Comments: A unique identifier for the person who may play various healthcare provider roles. This identifier is specific to the person not their roles.

This is the healthcare provider's UPI (Unique Provider Identifier).

UsageNotes: Queried health number shall be returned. If masked, the root and extension attributes shall be replaced by a nullFlavor mask attribute.

Rationale: Required attribute supports the identification of the healthcare provider

Design Comments: The provider person's name independent of any role they may play.

UsageNotes: If Principal Person is included in the message, then Person Name Must Exist.

If masked, the name attribute shall be replaced by a nullFlavor mask attribute. System shall support name parts (one prefix, up to two given, one family, and one suffix). Second occurrence of given indicates the middle name. All name parts are 50 characters in length.

Rationale: Required attribute supports the identification of the healthcare provider

Design Comments: The principal person's gender.

Rationale: Required attribute supports the identification of the healthcare provider

Design Comments: The provider person's date of birth.

UsageNotes: In the initial release Date of Birth will not be exposed (will be masked).

System shall support both 'YYYYMMDD' and the full TS.DATETIME data type as required. Should birthTime be masked, a nullFlavor mask attribute shall be present in place of the code attribute.

Rationale: Required attribute supports the identification of the healthcare provider

Design Comments: An indication that the provider person is deceased. Appropriate business process/function will need to be employed to ensure that validation or verification of the death event has been established prior to populating the message.

UsageNotes: Indicator shall be 'true' or indicator will be omitted otherwise. The indicator shall not be present should the indicator be masked.

Rationale: Required attribute supports the identification of the provider person.

Design Comments: Information about what language(s) should be used to communicate with the focal person can be sent in the LanguageCommunication class.

Rationale: Supports the business requirement to identify languages used by client for the purposes of communication

UsageNotes: Excluded from schemas

Design Comments: A token identifier assigned to the affiliation record.

Rationale: Used to retrieve the affiliation record.

Design Comments: A coded value indicating the type of affiliation between the healthcare provider and the affiliated organization.

Rationale: Allows distinguishing different kinds of affiliation.

Design Comments: An interval of time specifying the period during which this affiliation record is in effect, if such time limit is applicable and knowns

Rationale: Required attribute supports the identification of provider person affiliation.

UsageNotes: Excluded from schemas

UsageNotes: Excluded from schemas

Design Comments: The UPI of the affiliated provider organization.

Rationale: Mandatory attribute to support specifying healthcare provider's affiliation to provider organization.

UsageNotes: Excluded from schemas

Design Comments: A coded value indication the role of the affiliated provider organization.

Rationale: Mandatory attribute to support specifying healthcare provider to organization affiliation.

UsageNotes: Excluded from schemas

Mapping: Not Permitted

Design Comments: Identification number, other than healthcare provider license number, assigned to the provider.

Rationale: Additional information that may be used to positively identfy a provider.

Design Comments: A coded value that specifies the type of identifier assigned.

Rationale: Used to distinguish different types of identifiers, and is therefore mandatory.

Design Comments: Indicates the period of validity for the non-license identifier.

Rationale: Supports identification and authentication of a healthcare provider.

Design Comments: A code indicating the language of communication

Rationale: Required attribute conveying the expected language message elements are to be transmitted in

Design Comments: Indicates the healthcare provider's ability to communicate in the indicated language i.e. written, spoken, read

Rationale: Required attribute provides additional information about the healthcare provider's communication skills in a given language

Design Comments: Indicates the proficiency level at which healthcare provider is able to communicate in the indicated language of communication.

UsageNotes: Required attribute provides additional information about the healthcare provider's communication skills in a given language.

Not in use in the current release.

Design Comments: Indicates the preferred language for all communications.

Rationale: Required attribute that supports the business requirement to indicate the preferred language for all communications.

UsageNotes: Excluded from schemas

UsageNotes: Excluded from schemas

Design Comments: Unique identifier for the organization that assigned the specified roleClass identifier.

Rationale: Required attribute supports the validation and identification of the scoping organization assigning the id to the specified roleClass

Design Comments: 1. Organization that is responsible for registering the provider for a specific healthcare provider role. 2. Organization that grants the qualifications or expertise.

Rationale: Required attribute supports the validation and identification of the healthcare provider

Design Comments: Address for any of the supported roles 1. Issuing Organization 2. Qualification Granting Organization

Rationale: Required attribute supports the validation and identification of the healthcare provider

UsageNotes: Excluded from schemas

Design Comments: Unique identifier for the Credential.

UsageNotes: Not in use in the current release.

Rationale: Required attribute supports the identification of the healthcare provider credentials

Design Comments: A code for the degree or educational rank that the credential specifies.

UsageNotes: If Expertise or Credentials are included in the message, then Role Type Must Exist.

Rationale: Populated attribute supports the identification of the healthcare provider credentials

Design Comments: The effective date of the provider credentials in the healthcare provider role.

UsageNotes: If Expertise or Credentials are included in the message, then Role Effective Date Must Exist

Rationale: Populated attribute supports the identification of the healthcare provider credentials

UsageNotes: Excluded from schemas

Design Comments: A unique identifier for a provider in a specific healthcare role.

UsageNotes: Not in use in the current release. For detailed information about all provider’s licenses healthcareProviderLicensedEntity should be used. The root is an OID of the license issuing organization and needs to be obtained from a table IdentifierOriginSourceCode (cross-reference table of originCode and OID). The extension is the healthcare provider license number. If masked, the root and extension attributes shall be replaced by a nullFlavor mask attribute.

Rationale: Required attributes supports identification of a healthcare provider person.

Design Comments: The code identifying the specific healthcare provider role. E.g. MD - Medical Doctor, DEN - Dentist.

Rationale: Mandatory attribute supports the identification of the healthcare provider.

Design Comments: The provider's name pertaining to the specific provider role.

E.g. the name used by the provider in the role of a Medical Doctor, as opposed to the name in the role of a Dentist.

UsageNotes: Not in use in the current release. healthCarePrincipalPerson/name should be used to identify Provider ‘s names.

Rationale: Required attribute supports the identification of the healthcare provider.

Design Comments: The address for the provider when playing the role of healthcare provider.

UsageNotes: Not in use in the current release. providerRoleLocation/addr should be used to identify Provider’s addresses.

Rationale: Required attribute supports the identification of the healthcare provider.

Design Comments: The telecom for the provider when playing the role of healthcare provider.

Rationale: Required attribute supports the identification of the healthcare provider.

Design Comments: Not in use in the current release. providerRoleLocation/addr should be used to identify Provider’s telecoms.

Design Comments: The status of the provider in the healthcare provider role i.e. active / inactive profession.

Rationale: Required attribute supports the identification of the healthcare provider

Design Comments: The effective date of the provider in the healthcare provider role.

This is the effective date of the provider's license.

Rationale: Required attribute supports the identification of the healthcare provider

UsageNotes: Excluded from schemas

UsageNotes: Excluded from schemas

UsageNotes: Excluded from schemas

UsageNotes: Excluded from schemas

Design Comments: Indicates one of english or freanch as language in which the provider which to be communicated with the health system, in the spefici role.

Rationale: Facilitates communication with the health system.

UsageNotes: Excluded from schemas

Design Comments: A record of something that is being done, has been done, can be done, or is intended or requested to be done. Acts connect to Entities in their Roles through Participations and connect to other Acts through ActRelationships. Participations are the authors, performers and other responsible parties as well as subjects and beneficiaries (which includes tools and material used in the performance of the act, which are also subjects). The moodCode distinguishes between Acts that are meant as factual records, vs. records of intended or ordered services, and the other modalities in which act can appear.

Rationale: Acts are the pivot of the RIM; all domain information and processes are represented primarily in Acts. Any profession or business, including healthcare, is primarily constituted of intentional and occasionally non-intentional actions, performed and recorded by responsible actors. An Act-instance is a record of such an action.

UsageNotes: Excluded from schemas

UsageNotes: Excluded from schemas

Design Comments: Effective Time with regard to the act involved

UsageNotes: Required attribute indicating effective time of this act. Not in use in the current release.

UsageNotes: Excluded from schemas

Design Comments: Allows each Service Delivery Location to be sequentially listed.

UsageNotes: Excluded from schemas

Design Comments: A unique identifier for the provider delivery location.

UsageNotes: Required attribute supports the validation and identification of the service delivery location. Not in use in the current release.

Design Comments: The code identifying the specific practice (service delivery) location.

Rationale: Required attribute supports the validation and identification of the practice (service delivery location) where applicable

Design Comments: Address of the specific practice (service delivery) location.

UsageNotes: The 'use' attribute shall be populated with a type (WP, PST), with (optionally) additional indicators (BAD, CONF). The following data elements shall be present: unitId, houseNumberNumeric, buildingNumberSuffix, streetNameBase, streetNameType, direction, additionalLocator, streetAddressLine (up to 4 occurrences), city, state code, state text, postalCode, country code, country text. Address elements shall have delimiter tags indicating natural line breaks. Further address information will be captured within the addr element as delimited text, including delivery installation, PO BOX, and route service address information. Masked 'use' codes shall not be present, and masked addresses shall be represented by nullFlavor mask attribute. streetAddressLines may be a concatenation of the parsed address parts (unitId, houseNumberNumeric, buildingNumberSuffix, streetNameBase, streetNameType, direction, additionalLocator). Should country code not be recognized, the country code attribute shall be replaced by a nullFlavor unknown attribute.

Rationale: Populated attribute supports the validation and identification of the practice address.

Design Comments: The telecom for the business practice (service delivery) location.

UsageNotes: Telephone and fax numbers, email and web addresses shall be supported. Telecom use code shall consist of a type ('WP' - Work Place), optionally followed by 'BAD' (Invalid), 'CONF' (Confidential). Format of telephone/fax number value shall be 'tel:' or fax:' + (optionally) country calling code (Len 6) & area code (Len 3) & local number (Len 7) & (optionally for telephone numbers) extension (Len 6). Format of email address value shall be “mailto:” + email address (up to 100 characters). Format of web address value shall be “http://” or “https://” or “file://” or “nfs://” or “ftp://” + web address (up to 255 characters). System shall support multiple use codes. SpecializationType attribute shall distinguish between telephone/fax, email and web addresses. If masked, the specializationType shall be present and a nullFlavor mask shall be present.

Rationale: Required attribute supports validation and identification of telecom of provider person location.

Design Comments: An interval of time specifying the period during which this record in a provider registry is in effect, if such time limit is applicable and known.

UsageNotes: Low value shall be populated with the location effective date. High value shall be populated with the date at which the health business location is no longer valid. Should either low or high value be masked, the appropriate value attribute shall be replaced by a nullFlavor mask attribute.

Rationale: Required attribute supports the identification of the provider role location.

UsageNotes: Not in use in the current release.

UsageNotes: Excluded from schemas

UsageNotes: Excluded from schemas

UsageNotes: Excluded from schemas

UsageNotes: Excluded from schemas

Design Comments: A coded value indicating a specific jurisdiction of health information network within Ontario.

Rationale: Support jurisdictional nature of health service planning and delivery in Ontario.

Design Comments: The name associated with the LHIN number/code

Rationale: Allows for a health jrisdiction to be referenced by name.

UsageNotes: Excluded from schemas

UsageNotes: Excluded from schemas

Design Comments: A unique identifier for a provider in a specific healthcare role.

This is the License Certificate Number for a regulated healthcare provider.

Rationale: Required attribute supports the identification of a licensed healthcare provider

Design Comments: A coded value used to categorize licenses issued by specific issuing organizations.

Rationale: Supports role-based acces and permissions to be assigned at higher levels than the atomic healthcare provider role.

Design Comments: Indicates the start and end date for the license certificate.

Rationale: Required attribute to support the validity of the provider role license.

UsageNotes: Excluded from schemas

UsageNotes: Excluded from schemas

UsageNotes: Excluded from schemas

UsageNotes: Excluded from schemas

Design Comments: Unique identifier for the restriction.

Rationale: Required attribute supports the validation and identification of the healthcare provider and his/her given privileges

Design Comments: Type of restriction.

Rationale: Mandatory attribute supports the nature of the restriction.

Design Comments: Indicating that the privilege is a restriction.

Rationale: Mandatory attribute supports the notion that the information pertains to a retriction placed on a provider's license.

Design Comments: Comments and/or detailed description pertaining to the nature of the restriction. In some cases this will be a link to a web page that provides details of the restriction or limitation.

Rationale: Required attribute supports the validation and identification of the healthcare provider and the nature of restriction placed on the provider's license.

Design Comments: Effective date of the restriction.

UsageNotes: If Restrictions to Practice are included in the message, then Effective Date Must Exist

Rationale: Required attribute supports the validation and identification of the healthcare provider and his/her given privileges

Design Comments: Indicates the degree to which the restriction to practice is to be kept confidential.

Rationale: Required attribute supports the validation and identification of the healthcare provider and the extent of confidentiality of the restriction information.